Payment service to efficiently enable electronic payment

ABSTRACT

A method comprising communicating a web page, over a network, to a merchant server associated with a merchant. The web page includes a plurality of input mechanisms for receiving a plurality of reference return network addresses. The method further comprises receiving a first reference return network address, over a network, from the merchant, the first reference return network address being received at the payment service server, the first reference return network address identifying an interface that is hosted by a first merchant web site that is operated by the merchant and being utilized as a first landing page to which the consumer user is redirected to by the payment server to execute a transaction between the consumer user and the merchant. Finally, the method comprises storing the first reference return network address at the payment service server in user profile information that is associated with the merchant.

RELATED APPLICATIONS

This application is a continuation application which claims the prioritybenefit of U.S. application Ser. No. 13/160,316, filed Jun. 14, 2011,entitled “PAYMENT SERVICE TO EFFICIENTLY ENABLE ELECTRONIC PAYMENT,”which is a continuation that claims the priority benefit of U.S.application Ser. No. 12/198,664 filed Aug. 26, 2008, entitled “PAYMENTSERVICE,” which is a continuation that claims the priority benefit ofU.S. application Ser. No. 10/749,684, filed Dec. 31, 2003, issued asU.S. Pat. No. 7,457,778 on Nov. 25, 2008 and, entitled “METHOD ANDARCHITECTURE FOR FACILITATING PAYMENT TO E-COMMERCE MERCHANTS VIA APAYMENT SERVICE,” which claims the priority benefit of U.S. ProvisionalApplication No. 60/456,504, filed on Mar. 21, 2003, entitled “METHOD ANDARCHITECTURE FOR FACILITATING PAYMENT TO E-COMMERCE MERCHANTS VIA APAYMENT SERVICE,” which priority benefit is also claimed, and each ofwhich is incorporated herein in its entirety.

TECHNICAL FIELD

Example embodiments relate to a selective interface display system.

BACKGROUND INFORMATION

The past decade has seen a tremendous growth in the use of theworld-wide web for online purchases of products and services. Suchproducts are available via web sites provided by e-commerce merchants,such as electronic retailers. Typically, an e-commerce web site is builtaround a set of web pages that collectively comprise an “merchant.” Theweb pages generally include an electronic catalog of product offered bythe merchant (along with prices), and a product selection scheme thatoften corresponds to a “shopping cart model.” Toward the end of ashopping “experience” the customer is presented with one or more pagescorresponding to a “check out” or purchase transaction process. At thistime, the customer usually is asked to enter payment information, suchas a credit card number and billing address. In some instances, all orpart of this information may have been stored during a previous visitand is recalled based on user identification, e.g., through a loginprocess. After the payment information is entered, the customer is ableto finalize the transaction via a confirmation action, such asactivating a “confirm purchase” button displayed on a corresponding webpage.

In most instances, the only payment mechanism offered by e-commercemerchants for retail customers is via credit cards. There are manyreasons for this, including increasing the likelihood of receivingpayment for the goods, fraud protection, and accounting simplicity.However, credit card payments do not come without a cost. On themerchant side, a transaction fee is subtracted by the credit cardoperator (e.g., bank) that typically includes a base amount plus asecond amount based on a percentage of the overall purchase price (e.g.,1.5-2%). This leads to significant costs for larger merchants. From theconsumer's perspective, there are also many drawbacks pertaining tocredit card payments. Many consumers are weary about entering creditcard information on-line, and thus may not make purchases frome-commerce merchants. Furthermore, many consumers prefer not to usecredit cards for purchases, or do not have any credit cards to beginwith. Accordingly, it would be advantageous to provide an alternativepayment mechanism for both e-commerce merchants and consumers. Ideally,such an alternative payment mechanism should be easy to implement usingexisting network infrastructure.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same becomesbetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein likereference numerals refer to like parts throughout the various viewsunless otherwise specified:

FIG. 1 is an architecture and network flow diagram corresponding to afirst scheme for facilitating e-commerce merchant payment via athird-party payment service in accordance with one embodiment theinvention;

FIG. 2 is a flowchart illustrating further details of operationsperformed by the architecture of FIG. 1 during a consumer purchase froman e-commerce site;

FIG. 3 shows a web page via which merchants are enabled to specify oneor more URLs corresponding to web pages to which the consumer isredirected to during a purchase check out process; and

FIG. 4 is a schematic diagram illustrating a conventional computerserver that is suitable for practicing embodiments of the inventiondisclosed herein.

DETAILED DESCRIPTION

Embodiments of methods and architectures for facilitating electronicpayment of goods and services corresponding to on-line purchases aredescribed herein. In the following description, numerous specificdetails are set forth to provide a thorough understanding of embodimentsof the invention. One skilled in the relevant art will recognize,however, that the invention can be practiced without one or more of thespecific details, or with other methods, components, materials, etc. Inother instances, well-known structures, materials, or operations are notshown or described in detail to avoid obscuring aspects of theinvention.

Reference throughout this specification to “one embodiment” or “anembodiment” means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the present invention. Thus, theappearances of the phrases “in one embodiment” or “in an embodiment” invarious places throughout this specification are not necessarily allreferring to the same embodiment. Furthermore, the particular features,structures, or characteristics may be combined in any suitable manner inone or more embodiments.

In accordance with aspects of the present invention, methods andarchitectures are disclosed herein for facilitating payment of goods andservices via a third-party electronic payment service (i.e., the“payment service” or simply “service”). More particularly, thearchitectures provide efficient mechanisms for enabling payment of goodsand services offered by e-commerce merchants via the payment service onan individual consumer basis. The mechanisms enable e-commerce merchantsto easily add payment via the service as an option to authorizedcustomers, and seamlessly integrate transactions via the payment serviceinto the merchant's check out process. Furthermore, the architectureenables identification of consumers who are authorized to use thepayment service without requiring the service to disseminate anycustomer lists or the like to e-commerce merchants that use themechanisms.

In one embodiment, the mechanism is facilitated via an applicationprogram interface (API) and corresponding cookies relating to the APIand use of the payment service. A service cookie is sent to theconsumer's computer (and subsequently stored thereon) when the consumerlogs into the payment service's website. For example, when a consumersigns up to use the payment service, a service cookie is sent back tothe consumer's device (e.g., computer) to be stored on that device by abrowser. The cookie is then used to facilitate future transactions viathe service. Based on the existence of the service cookie, the servicecan determine whether the consumer has ever successfully logged into theservice website. If an appropriate cookie has been sent to the consumer(actually the device), indicating the consumer is authorized to use theservice, the service will advise the merchant, via the API, to allow theconsumer to use the payment service for a current purchase. Accordingly,the merchant will present a checkout process congruent with the use ofthe service as a payment option.

An architecture and process flow diagram 100 corresponding to oneembodiment of the invention is shown in FIG. 1, while a flowchartfurther describing the operations performed via the architecture isshown in FIG. 2. The process begins in a block 200 in which the merchantsigns an agreement with the payment service to use the payment serviceAPI for facilitating consumer payment via the service. An administratoror the like at the payment service then enables the merchant for APIaccess. In one embodiment the merchant is enabled for API access via anadmin tool that is used to administrate user's accounts.

Next, in a block 202, the merchant specifies a return URL for itswebsite. In one embodiment user's of the payment service, includingmerchants, are enabled to provide one or more return URLs for respectivesites operated by the merchant via a user profile page hosted by theservice, such as depicted in FIG. 3. The merchant simply enters the URLaddress for each web page that merchant wants the flow to be re-directedfrom the payment service site, as described below in further detail.

The final step for enabling use of the API is completed when themerchant incorporates the payment service's API into appropriate webpages on its web site, as depicted by a block 204. These web pages willtypically include one or more pages leading to a check out flow for thesite. The one or more pages are collectively represented by merchantpage 1 in FIG. 1—it will be understood that the provisions discussedbelow corresponding to merchant page 1 should be included in each of theweb pages corresponding to the initial portion of a check out process.At this point, the merchant and service websites are configured tofacilitate consumer payments via the payment service.

During subsequent ongoing operations, various consumers are enabled toprovide payment for products purchased from the merchant via the paymentservice in the following manner. Generally, consumer's will access themerchant website via a web-enabled device, such as a Macintosh computer102, personal computer (PC) 104, and laptop 106 depicted in FIG. 1. Itis noted that these are merely exemplary web-enabled devices thatconsumer may use, with other devices including but not limited to PDA's,pocket PC's, web-enabled phones, workstations, etc. For clarity,augmentations to the network architecture for supporting non-HTMLbrowsers, such as the micro-browsers used in PDA's and web-enabledphones, are not shown or discussed herein; infrastructure for extendingweb access to such devices are well-known in the art.

Continuing in a block 206, a consumer operating the web-enabled device,visits the merchant's website and selects one or more products forpurchase, e.g., via “placing” the products in an electronic shoppingcart. The consumer then initiates the site's check out process byactivating an appropriate button displayed on Merchant page 1, such as a“Check Out” button 108. In response, a set of operations correspondingto blocks 208, 210, 212, and 214 are performed substantially instantlyin a manner that is transparent to the consumer.

First, in block 208 the consumer (i.e., the browser on the consumer'sdevice) is directed to merchant page 1.3, which comprises a blank page(with regard to visual content). Merchant page 1.3 is embedded with codeto redirect the device's browser to page 1.6 hosted by the paymentservice. During this operation, information identifying the merchant(i.e., a merchant ID) is passed from the merchant's web server to theservice's server. For example, in one embodiment, the browser isredirected to the service's server using a URL having the followingformat:

https://<service_web_address>/cgi-bin/webscr?cmd=_user-check&MID=X@Y.com&URL=http://www.Y.com/cgi-bin/checkoutpg2where <service_web_address> is the address for the payment service'shome page, and “MID” is the merchant ID with the payment service, whichin the current example comprises a primary email address (X@Y.com) ofthe merchant. “URL” is the return URL of the web page to where theconsumer user is to be redirected to.

Upon receiving the merchant ID, the service server checks its userprofile data to verify that the merchant is enabled for API use in block210. In one embodiment, data embedded in the foregoing URL formatprovides a built-in security measure, wherein the MID and URL values arechecked against user profile information for the merchant toauthenticate the request. Accordingly, if the merchant decides to renameits “page 2” URL, the merchant will need to update the corresponding URLentered in the user profile above in connection with block 202 and FIG.3. If the merchant is not enabled, an indicator is sent back to themerchant server indicating such via the reply discussed below.

Upon verifying that the merchant is enabled for API use, a CGI (commongateway interface) command (script) is executed on the service's serverto interpret the consumer's service cookie. In conjunction with theredirect to service URL above, the browser on the consumer's deviceautomatically forwards a copy of the cookie back to the service server.This is a process that is automatically performed by modern browser'sthat support cookies in response to being directed to a website thatissued the cookie, and does not require any modification on the client(i.e., consumer device) side. In essence, a cookie is merely a pied oftext that a web server sends to a client (e.g., a browser running on theconsumer's device) to have stored on the client for subsequent use. Eachcookie contains information comprising name-value pairs that may be usedby the issuing web site during subsequent interactions with the site totransfer information to the site without requiring any action by theuser. Typically, such information includes user ID's and the like.

Based on the merchant's return URL, the CGI command redirects thebrowser back to the merchant's web server to merchant page 2, whichbegins the augmented check out flow. In conjunction with this, a replyis passed to the server (e.g., embedded as a variable in a pre-formattedURL in one embodiment) that indicates whether or not the consumer isauthorized to use the payment service. In one embodiment respectivereply variable values are also used to indicate an authenticationfailure and a cookie cannot be interpreted.

The merchant server extracts the reply variable passed from service page1.6 and dynamically changes the flow of the check out process beginningat merchant page 2. For example, if a cookie is not received from theconsumer's device, the consumer is not authorized to use the paymentservice. Accordingly, the reply will indicate such, and the portion ofthe check out flow beginning with merchant page 2 will continue with acheck out process that doesn't present the consumer with an option topay via the payment service. In contrast, if the reply indicates theconsumer is an authorized user, the merchant page 2 will lead to one ormore subsequent pages (not shown) that will enable the user to pay forthe purchase via the payment service. Typically, these pages will becoded by the merchant to fit the particular check-out process preferredby the merchant. Generally, the checkout process will perform abehind-the-scenes interaction with the payment service to complete apayment transaction in response to a consumer's authorization to pay forthe product using the payment service. Further details of this processare known in the art, and, as such, are not disclosed herein.

The foregoing scheme provides an efficient mechanism for enablinge-commerce merchants to offer purchase payments via third-party paymentservices. This is advantageous to both the merchant and consumers. Thecost associated with credit card transactions fees are eliminated formost payment service transactions. Like credit cards, payments issued bythe payment services are trustworthy. Consumers also enjoy the benefitof being able to purchase products on-line in a secure manner thatdoesn't require disclosure of credit card information, or even requirethe consumer to possess a credit card.

Exemplary Server Computer System

With reference to FIG. 4, a generally conventional computer server 400is illustrated, which is suitable for use in connection with practicingthe embodiments of the present invention discussed above. For example,computer server 400 may be used for running software modules andcomponents on the merchant web server and service server to facilitatethe operations in the flow diagrams and flowcharts discussed above.Examples of computer systems that may be suitable for these purposesinclude stand-alone and enterprise-class servers operating UNIX-basedand LINUX-based operating systems, as well as servers running theWindows NT or Windows 2000 Server operating systems.

Computer server 400 includes a chassis 402 in which is mounted amotherboard 404 populated with appropriate integrated circuits,including one or more processors 406 and memory (e.g., DIMMs or SIMMs)408, as is generally well known to those skilled in the art. A monitor410 is included for displaying graphics and text generated by softwareprograms and program modules that are run by the computer server. Amouse 412 (or other pointing device) may be connected to a serial port(or to a bus port or USB port) on the rear of chassis 402, and signalsfrom mouse 412 are conveyed to the motherboard to control a cursor onthe display and to select text, menu options, and graphic componentsdisplayed on monitor 410 by software programs and modules executing onthe computer. In addition, a keyboard 414 is coupled to the motherboardfor user entry of text and commands that affect the running of softwareprograms executing on the computer. Computer server 400 also includes anetwork interface card (NIC) 416, or equivalent circuitry built into themotherboard to enable the server to send and receive data via a network418, such as the Internet, enabling the server to be connected to theworld-wide web.

File system storage for storing server-side data, such as user profiles,electronic catalogs, CGI scripts, etc. may be implemented via aplurality of hard disks 420 that are stored internally within chassis402, and/or via a plurality of hard disks that are stored in an externaldisk array 422 that may be accessed via a SCSI card 424 or equivalentSCSI circuitry built into the motherboard. Optionally, disk array 422may be accessed using a Fibre Channel link using an appropriate FibreChannel interface card (not shown) or built-in circuitry. Other harddisk interfaces may also be used.

Computer server 400 generally may include a compact disk-read onlymemory (CD-ROM) drive 426 into which a CD-ROM disk may be inserted sothat executable files and data on the disk can be read for transfer intomemory 408 and/or into storage on hard disk 420. Similarly, a floppydrive 428 may be provided for such purposes. Other mass memory storagedevices such as an optical recorded medium or DVD drive may also beincluded. The machine instructions comprising the software componentsthat cause processor(s) 406 to implement the operations of theembodiments discussed above will typically be distributed on floppydisks 430 or CD-ROMs 432 (or other memory media) and stored in one ormore hard disks 420 until loaded into memory 408 for execution byprocessor(s) 406. Optionally, the machine instructions may be loaded vianetwork 418 as a carrier wave file.

Thus, embodiments of this invention may be used as or to support asoftware program executed upon some form of processing core (such as theCPU of a computer) or otherwise implemented or realized upon or within amachine-readable medium. A machine-readable medium includes anymechanism for storing or transmitting information in a form readable bya machine (e.g., a computer). For example, a machine-readable medium caninclude such as a read only memory (ROM); a random access memory (RAM);a magnetic disk storage media; an optical storage media; and a flashmemory device, etc. In addition, a machine-readable medium can includepropagated signals such as electrical, optical, acoustical or other formof propagated signals (e.g., carrier waves, infrared signals, digitalsignals, etc.).

The above description of illustrated embodiments of the invention,including what is described in the Abstract, is not intended to beexhaustive or to limit the invention to the precise forms disclosed.While specific embodiments of, and examples for, the invention aredescribed herein for illustrative purposes, various equivalentmodifications are possible within the scope of the invention, as thoseskilled in the relevant art will recognize.

These modifications can be made to the invention in light of the abovedetailed description. The terms used in the following claims should notbe construed to limit the invention to the specific embodimentsdisclosed in the specification and the claims. Rather, the scope of theinvention is to be determined entirely by the following claims, whichare to be construed in accordance with established doctrines of claiminterpretation.

1. A method comprising: communicating a web page, over a network, to amerchant server associated with a merchant, the web page including aplurality of input mechanisms for receiving a plurality of referencereturn network addresses; receiving a first reference return networkaddress, over a network, from a merchant, the first reference returnnetwork address being received at a payment service server, the firstreference return network address identifying an interface that is hostedby a first merchant web site that is operated by the merchant and beingutilized as a first landing page to which a consumer user is redirectedto by the payment server to execute a transaction between the consumeruser and the merchant; and storing the first reference return networkaddress at the payment service server in user profile information thatis associated with the merchant.
 2. The method of claim 1, furthercomprising receiving a cookie and merchant information, over thenetwork, from a browser that is associated with the consumer user, themerchant information identifying the merchant and the cookie identifyingthe consumer user.
 3. The method of claim 2, wherein the merchantinformation includes a merchant identifier (MID) that identifies themerchant.
 4. The method of claim 3, wherein the MID includes an emailaddress.
 5. The method of claim 2, wherein the receiving the merchantinformation includes receiving a return network address that identifiesthe interface hosted by the first merchant web site.
 6. The method ofclaim 1, further comprising: receiving a second reference return networkaddress, over the network, from the merchant, the second referencereturn network address being received at the payment service server, thesecond reference return network address identifying a second interfacehosted by a second merchant web site that is operated by the merchant.7. The method of claim 6, wherein the second interface hosted by thesecond merchant web site is a second landing page to which the consumeruser is redirected to by the payment service server to execute atransaction between the consumer user and the merchant.
 8. The method ofclaim 1, wherein the plurality of input mechanisms includes a firstinput mechanism, wherein the first input mechanism is utilized toreceive the first reference return network address.
 9. The method ofclaim 1, wherein the plurality of input mechanisms includes a secondinput mechanism, wherein the second input mechanism is utilized toreceive the second reference return network address.
 10. The method ofclaim 1, further comprising communicating a reply that includes anauthorization to use the payment service server.
 11. A non-transitorymachine readable medium that stores instructions that, when executed bya machine, cause the machine to: communicate a web page, over a network,to a merchant server associated with a merchant, the web page includes aplurality of input mechanisms to receive a plurality of reference returnnetwork addresses; receive a first reference return network address,over a network, from a merchant, the first reference return networkaddress is received at a payment service server, the first referencereturn network address identifies an interface that is hosted by a firstmerchant web site that is operated by the merchant and is utilized as afirst landing page to which a consumer user is redirected to by thepayment server to execute a transaction between the consumer user andthe merchant; and store the first reference return network address atthe payment service server in user profile information that isassociated with the merchant.
 12. The non-transitory machine readablemedium of claim 11, wherein the machine receives a cookie and merchantinformation, over the network, from a browser that is associated withthe consumer user, the merchant information identifies the merchant andthe cookie identifies the consumer user.
 13. The non-transitory machinereadable medium of claim 12, wherein the merchant information includes amerchant identifier (MID) that identifies the merchant.
 14. Thenon-transitory machine readable medium of claim 13, wherein the MIDincludes an email address.
 15. The non-transitory machine readablemedium of claim 12, wherein the machine receives a return networkaddress that identifies the interface hosted by the first merchant website.
 16. The non-transitory machine readable medium of claim 11,wherein the machine receives a second reference return network address,over the network, from the merchant, the second reference return networkaddress is received at the payment service server, the second referencereturn network address identifies a second interface hosted by a secondmerchant web site that is operated by the merchant.
 17. Thenon-transitory machine readable medium of claim 16, wherein the secondinterface hosted by the second merchant web site is a second landingpage to which the consumer user is redirected to by the payment serviceserver to execute a transaction between the consumer user and themerchant.
 18. The computer implemented non-transitory machine readablemedium of claim 11, wherein the plurality of input mechanisms includes afirst input mechanism, wherein the first input mechanism is utilized toreceive the first reference return network address.
 19. The computerimplemented non-transitory machine readable medium of claim 11, whereinthe plurality of input mechanisms includes a second input mechanism,wherein the second input mechanism is utilized to receive the secondreference return network address.
 20. The computer implemented method ofclaim 11, wherein the machine communicates a reply that includes anauthorization to use the payment service server.